Security concerns for all types of processor-based electronic devices, and particularly for computing devices, have become a significant concern. While some concerns may relate to detrimental actions which may be undertaken by defective code implemented by such devices, the greater concerns relate to the ramifications of various types of attacks made upon such devices through malicious code, including code conventionally known in the field by a number of names, including “viruses,” “worms,” “Trojan horses,” “spyware,” “adware,” and others. Such malicious code can have effects ranging from relatively benign, such as displaying messages on a screen, or taking control of limited functions of a device; to highly destructive, such as taking complete control of a device, running processes, transmitting and/or deleting files, etc. Virtually any type of imaginable action on a processor-based device has been the subject of attacks by malicious code.
Many of these attacks are directed at computing devices, such as workstations, servers, desktop computers, notebook and handheld computers, and other similar devices. Many of these computing devices can run one or more application programs which a user may operate to perform a set of desired functions. However, such attacks are not limited to such computing devices. A broader group of various types of devices, such as cell phones; personal digital assistants (“FDA's”); music and video players; network routers, switches or bridges; and other devices utilizing a microprocessor, microcontroller, or a digital signal processor, to execute coded instructions have been the subjects of attacks by malicious code.
In one particular situation, one application such as a browser application may have to invoke a plugin (also referred to as an application extension), which may be developed by a third party. Typically, when an application invokes a plugin that is associated with the application (also referred to as a host application), the operating system launches the plugin within the same process address space of the application, as shown in FIG. 1. Referring to FIG. 1, when application 104 invokes plugin 105, application launch module 102 of an application manager 101 loads plugin 105 within the same process address space 106 of application 104. Since application 104 and its plugin 105 are running within the same address space 106, plugin 105 may be able to access resources that are accessible by application 104, where the resources may be managed by resource manager 103. From the view point of resource manager 103, application 104 and plugin 105 are the same process. That may cause application 104 to be vulnerable if plugin 105 turns out to be malware.
For example, if plugin 105 is a third party plugin developed for application 104 and if application 104 can access a local storage and a network, plugin 105 may exploit and attack the files stored in the local storage and the network. In addition, even if plugin 105 is not malware, when plugin 105 crashes, it may bring down application 104 or cause application 104 to malfunction. Furthermore, when plugin 105 is terminated by launch module 102, the termination of plugin 105 may cause application 104 unstable since they are in the same process address space 106.
A conventional system utilizes a customized universal resource locator (URL) scheme for inter-process communications between two applications, which suffers from discoverability limitations, security concerns, and a general lack of flexibility where bi-directional communication is difficult and fragile. The URL schemes may cause an application to switch to the host application, which may bump the user out of the initiating application and destroy any of the visual context and the associated workflow will be lost. It is very difficult to detect such a situation.
A number of methodologies have been used in an attempt to reduce or eliminate both the attacks and influence of malicious or defective code. Generally, these methodologies include detection, prevention, and mitigation. Specifically, these methodologies range from attempts to scan, identify, isolate, and possibly delete malicious code before it is introduced to the system or before it does harm (such as is the objective of anti-virus software, and the like), to restricting or containing the actions which may be taken by processes affected by malicious or defective code. However, there has been a lack of efficient ways for handling a plugin associated with an application that invokes another application in a secured manner.